第一天我寫下了這句話：
系統會走樣，不是因為 AI 做不好，而是講過的決定沒有被系統化地留下來。
當時這句話只是根據過去的開發經驗提出的觀察，30 天之後，我有了更多實際證據。
昨天盤點了整個開發過程中的 8 筆返工，都是我當初沒有想清楚的需求，或是我訂下的規則沒有被驗證，因此這 30 天也讓我重新修正了第一天的說法，問題不只是決定有沒有被留下來，而是留下來的規則是否清楚、是否一致，以及有沒有辦法驗證。
這是整個系列裡反覆出現、換了好幾個面貌的同一件事。
契約中的權限定義不清楚： 我在契約裡寫了「任何人」，本意是「任何登入的使用者」。AI 按照字面理解，做出了八個不需要 Token 的端點，而測試也依照同一份契約撰寫，結果全部通過。
前一個工作單元的慣例被錯誤延續： 前四個工作單元的資料表都有 Trigger。如果第五個工作單元沒有特別說明，AI 可能會延續既有做法，即使第五個工作單元的執行狀態本來就應該允許變更。
永遠通過的型別檢查： 一個實際上無法檢查任何問題的指令，被寫進專案規範，卻一直沒有人發現，因為它從來沒有報錯。
這些問題有一個共同點：
錯誤不一定會以紅燈的形式出現，也可能以「一致」的形式存在。
AI 依照同一份模糊的規格完成實作與測試，兩邊的結果自然可能一致。但一致不代表正確，測試全綠也不代表需求本身沒有問題。因此，規範真正要處理的，不只是「AI 出錯」，還有需求中的模糊、規則之間的矛盾，以及缺乏驗證的地方。
接下來這份 SOP，就是我根據這 30 天的實作經驗，針對這些問題整理出來的做法。
以下是我目前整理出的 13 條規則，它不是一份要求 AI 遵守的指令清單，而是從規格、開發、測試到交付，明確定義每個階段該做什麼、如何驗證，以及人應該在哪些地方介入。
依照開發流程分成四個階段
1. 明確描述規則、關鍵欄位與例外
不要只描述正常情境，也要明確定義關鍵欄位的型別、可否為空、狀態轉換，以及例外情況。例如，「送出後不可修改」還不夠，還要釐清哪些欄位不能修改、是否允許刪除，以及退回草稿後能不能重新編輯。
規格沒有定義的地方，AI 可能會自行補上看似合理的行為。因此，重要的業務規則與例外，都應該在實作前確認。
2. 保留重要決策及理由；易變資訊重新查證
規格不只要記錄最後的決定，也要保留為什麼這樣決定。例如，為什麼選擇使用資料庫 Constraint，而不是只在 Service 層檢查？為什麼某個欄位要在送出時建立快照？當 AI 或其他開發者接手時，這些理由能幫助他們理解設計，而不是只看到一個結果。
但技術文件、套件版本與外部 API 等容易變動的資訊，不應只依賴舊文件，必要時要重新查證。
3. 說明每條規則由哪個層級強制執行
規則寫在文件裡，不代表系統真的會遵守。
每條重要規則都應該明確指出由哪個層級負責，例如：
如果某條規則只能依賴 AI 閱讀文件後自行遵守，就應該清楚知道它的限制，而不是誤以為已經有機制保護。
4. 每個工作單元遵循 RED → GREEN → IMPROVE，並留下測試先行的紀錄
每個工作單元都依照 RED → GREEN → IMPROVE 的順序進行：
我要求至少留下兩次 Commit：先提交測試，再提交實作。這樣不只是在流程上要求測試先行，也能從 Git 紀錄中確認實際順序。
5. 確認測試因預期的違規而失敗，並同時驗證正向與反向情境
測試變紅，不代表測試一定有效。有時候測試只是因為匯入失敗、環境設定錯誤，或其他無關問題而失敗。因此，寫完測試後，必須確認失敗原因確實是尚未實作預期功能。同時，測試不能只驗證「不允許做什麼」，也要確認「應該允許的行為確實能成功」。
例如，測試已送出的版本不能修改時，也要先確認正常建立與送出版本的流程能成功。否則，即使系統完全不允許修改，也可能只是因為整個功能根本無法使用。
6. 透過 HTTP 驗證核心端到端流程
單元測試與資料庫測試可以確認局部行為，但不代表整個系統真的能運作。對於核心功能，我會透過 HTTP 從使用者實際操作的角度，驗證完整流程。例如，從登入開始，建立會議、撰寫紀錄、送出版本，再由參與者確認，最後檢查版本是否生效。
這類測試能發現跨越 API、Service、Repository、資料庫等不同層級的整合問題，也能確認前後端串接後，核心使用情境是否真的成立。
7. AI 驗證明確的驗收條件；人補充未明確的需求並確認結果
規格中能明確描述、也能自動驗證的條件，應該交給 AI 執行測試。但測試通過，不代表功能就一定符合使用者真正的期待。因此，人工驗收仍然不可少。人需要從實際使用情境出發，檢查規格沒有寫清楚的部分，並判斷目前的操作流程與結果是否符合需求。
如果人工驗收發現了原本沒有定義的條件，就應該把它補進規格或測試，而不是只在當下修正。
8. 要求 AI 提供驗證證據，不只接受結論
AI 回報「測試通過」或「功能完成」，不代表真的完成了驗證。我會要求 AI 提供具體證據，例如執行了哪些測試、測試結果、修改了哪些檔案，以及哪些條件尚未驗證。尤其是 CI、Hook 這類守門機制，不能只看畫面上顯示的文字，還要確認實際執行結果與 Exit Code。
9. 將 Review 發現拆成可獨立驗證的項目
Review 經常會出現「這裡可能有問題」或「這樣的設計不太合理」等描述。這些意見如果沒有進一步拆解，AI 可能只修改表面上的程式碼，卻沒有真正解決問題。因此，我會要求把 Review 發現拆成可以獨立驗證的條件。例如，將「這個 API 的權限檢查有問題」拆成「未登入時應回傳 401」、「非擁有者不能讀取未送出的紀錄」等具體情境。
這樣才能將模糊的意見轉成測試，並確認問題是否真的被修正。
10. 規格或契約變更後，重新檢查既有實作
規格不是實作前寫完就不再變動的文件。
開發過程中，可能會因為測試、Review 或新的需求而修改規格。這時不能只讓 AI 按照新規格繼續開發，也要檢查既有程式碼是否仍符合新的定義。
例如，原本只要求版本內容在送出時不可修改，後來又補充參與者快照也不能被刪除。這不只是新增一個測試，還要確認資料庫的 Trigger、既有 API 與相關測試是否都符合更新後的規則。
11. 每個 Gate 都要實際測試，確認違規時會被攔截
測試、Hook、CI 都可以成為開發流程中的 Gate，但設定完成不代表它真的有效。每個 Gate 都應該至少進行一次反向驗證：刻意製造違規情境，確認它確實會阻止流程繼續。例如，故意讓測試失敗，確認 Stop Hook 會阻止 AI 結束工作；故意讓 CI 檢查不通過，確認工作流程會呈現失敗狀態。
如果沒有實際測試過，就不能只因為設定檔存在，就認定這個 Gate 已經生效。
12. 不為了讓 CI 變綠而降低品質門檻
CI 失敗時，應該先找出真正的原因，而不是直接降低測試門檻，讓它重新變綠，例如：原本要求所有測試通過，卻因為某個測試失敗而降低檢查範圍，可能只是把問題藏起來。
如果確實有合理的例外，也應該記錄原因與影響範圍，而不是默默調整設定。CI 的目的不是讓每次提交都顯示綠色，而是讓團隊知道目前的程式碼是否符合既定的品質要求。
13. 收工前完成交付檢查；確認 Issue 狀態與實際交付一致
每個工作單元結束前，都應該進行一次收尾檢查，確認：
Issue 被標記為完成，不代表工作真的完成。即使 Commit 使用了 Closes #，也應確認實際的交付內容與 Issue 狀態。收尾的目的不是多做一次形式上的檢查，而是避免工作看起來已經結束，實際上卻留下未完成的項目。
1. 規則會累積，也需要定期清理
開發過程中，規格、指令、Hook 和測試會不斷增加。但新增規則不代表系統就會更可靠。過期的文件、失效的設定，以及已經不適用的限制，都可能讓 AI 遵循錯誤的資訊。
因此，除了建立規則，也要定期檢查哪些規則已經失去作用。
2. 有上下文的人，反而容易忽略上下文的變化
開發者知道系統為什麼這樣設計，也記得哪些決策曾經改變。但 AI 每次接手時，能取得的資訊可能不同；即使是同一個人，也可能忘記先前做過的決定。
因此，重要的決策不能只存在於對話或個人記憶中，而要留下可追溯的紀錄。
3. AI 開發的成本，不只有產出，還包括理解與驗證
AI 能快速產生程式碼，但產出越快，不代表整個開發流程就越快。
規格、測試、Review 和整合，都需要人理解 AI 做了什麼、判斷結果是否正確。當產出速度提高，這些環節反而可能成為新的瓶頸。
所以，AI-Native Development 不只是讓 AI 寫更多程式碼，而是重新設計人與 AI 的分工，讓產出、驗證與決策能夠配合。
回到第一天那個問題：AI 什麼都能做，為什麼系統做出來還是走樣了？
30 天之後我的答案是：它沒有走樣，它非常精確地做出了我描述的那個東西。 走樣的是我以為我描述的，跟我實際描述的，中間那段差距。規範不是為了管 AI，是為了讓那段差距現形。
感謝讀到這裡的每一位，這個系列到這裡就告一段落了，有問題歡迎在底下留言！
iThome鐵人賽
看影片追技術